A file plan may be described as a set of containers (e.g., folders) and records. The containers may hold records and other containers.
Record management file plan organization is primarily structured to meet customer business logic or business organizational requirements, as in the following examples:                Organizational Structure                    Human Resources, Finance, Legal                        Categorization around topics, themes, or context                    personnel files, loan documents, legal cases                        Business States                    Inbox vs. Outbox, Active vs. Archived documents                        
Such business-oriented file plan organizations often become unbalanced with respect to the number of individual records contained within individual file plan containers. While some such containers may have a relatively small number of records, others may reach record populations on the order of hundreds of thousands to even multiple millions of records.
While such an unbalanced record population distribution may be manageable from the customer's point of view (e.g., search mechanisms are used for desired records in lieu of browsing large containers), it can have an impact on the performance of other records management application tasks, such as disposition processing, hold management, report generation, etc. These types of application tasks often need to examine record-level criteria and, as such, involve queries against all records contained either directly within or below some file plan container hierarchy node. Such queries may be very time consuming to execute (which affects performance of other aspects of the application) and are not always amenable to typical performance improvement techniques such as the use of additional database indices.
Currently, there is an entity count limit on the number of file plan entities that may be associated with an individual workflow task instance. This entity count limit results in the need to create and manage multiple workflow task instances for a given logical workflow task when the number of entities involved is greater than the entity count limit. This results in a more complicated user experience when the user processes workflow tasks within a workflow inbox.